The approaches described in this section could be pursued, but are not necessarily approaches that have been previously conceived or pursued. Therefore, unless otherwise indicated herein, the approaches described in this section are not prior art to the claims in this application and are not admitted to be prior art by inclusion in this section.
The Internet has become an important tool for businesses and consumers alike. Businesses use the Internet to improve overall efficiency. For example, businesses can use the Internet to share critical data with remote offices or to enhance communications with business partners. Consumers use the Internet to enrich their lives. For example, consumers use the Internet to purchase goods and services from the comfort of their own homes or to find and use the vast amount of information that is available on the Internet. As both businesses and consumers utilize the Internet more and more, it is more important than ever that the Internet is protected from disruption by malicious entities via denial of service attacks (“DoS”). DoS attacks deprive legitimate users of access to services on the Internet, and have been used successfully to disrupt legitimate user access to websites such as Yahoo and CNN.
One type of DoS attack takes advantage of the basic design of the Transmission Control Protocol (“TCP”), one of the foundational protocols of the Internet. This type of DoS attack, known as a SYN-flood DoS attack, exploits the fact that TCP requires a “three-way handshake” to establish a connection between a client and a server. In a SYN-flood attack, the attacker sends many SYN packets with unreachable or spoofed source addresses, in rapid succession, to the victim. The victim will store the incomplete connections in a backlog queue and attempt to complete the connections initiated by the SYN packets. However, because the source addresses of the SYN packets are unreachable or spoofed, the connections are never completed and the backlog queue accumulates until it is filled up to capacity with incomplete connections. Once the backlog queue is filled up, legitimate users can no longer connect to the victim. As a result, services on the victim are denied to legitimate users.
One possible approach in dealing with SYN-flood attacks is an “intercept” approach. In this approach, an intermediary intercepts SYN packets from a client. The intermediary attempts to establish a connection with the source of the SYN packet (which should be the client if the packet is a part of a legitimate connection attempt). If the connection establishment is successful, the intermediary establishes a connection with the server. The intermediary then merges the two connections together to form a connection between the client and the server. The intermediary also has aggressive timeouts that will terminate illegitimate connection requests quickly so that valid requests can still be serviced.
One implementation of the intercept approach is provided as the intercept mode in the TCP Intercept feature in IOS software made by Cisco Systems, San Jose, Calif.
However, this approach has numerous disadvantages. One problem is that this approach, by actively intercepting connection requests and establishing intermediate connections, adds additional latency to a connection attempt. Another problem is that this approach does not support TCP options that are negotiated on the TCP three-way handshake. Another problem is that this approach is inflexible. In the intercept approach, whenever an attack is suspected, the “attacking” connection is terminated. This may not be the best course of action in all instances, nor is this the action that an administrator will necessarily choose. An administrator may wish to monitor the suspected attack further, to gain a better understanding of the situation. In addition, the intercept approach does not provide the administrator with any additional info for analysis.
Another approach for is the “watch” approach. In this approach, the intermediary lets the SYN packets through to the server, but monitors the connection attempt until the connection is established or the attempt times out. If the attempt times out, the intermediary will terminate the attempt.
One implementation of the watch approach is provided as the watch mode in the TCP Intercept feature in IOS software made by Cisco Systems, San Jose, Calif.
While the watch approach is less intrusive than the intercept approach, it still has some disadvantages. One disadvantage is that it still terminates the attempt after the timeout rather than giving the administrator discretion on what action to take. This approach also provides no useful information to the administrator for analysis.
A third approach is to check the source address of a received SYN packet in a domain name server (“DNS”), to verify the existence of the address. This reverse DNS lookup approach also has some disadvantages. One disadvantage is that the source address may be a spoofed legitimate address rather than just an unreachable address. If the address is a spoofed address, the reverse DNS lookup will yield a positive response for the address even if the SYN packet is part of an attack. Thus, this approach may determine that a packet transmission is not an attack even though it actually is, i.e. a false negative. A second disadvantage is that the reverse DNS lookup introduces additional latency into the connection attempt. A third disadvantage is that this approach depends on a DNS system that is beyond the control of the administrator. If a connection to the DNS system or the DNS system itself is inoperative, this approach is useless.
Based on the foregoing, there is a clear need for a more passive and flexible way to detect SYN-flood DoS attacks and provide information to the administrator for analysis.
There is also a need for a way to detect another type of DoS attack, called a SYN-RST (syn-reset) attack. This attack involves sending a SYN packet and then a RST packet, or a SYN packet, a few extra packets to deceive the victim into determining that the connection attempt is legitimate, and then a RST packet. Many SYN-RST groups sent in succession may keep the victim server busy enough such that legitimate connection requests will not be serviced.